ソフトウェア開発プロジェクトにおいて、ソフトウェアの品質向上に時間をかけるか、より価値のある機能のリリースに集中するかという議論は一般的です。通常、機能をデリバリーするプレッシャーが議論を支配し、多くの開発者はアーキテクチャやコードの品質に取り組む時間がないと不満を漏らします。この議論は、品質向上はコスト増加につながるという仮定に基づいており、これは私たちの一般的な経験です。しかし、直感に反する現実として、内部ソフトウェアの品質を高めることで、新機能の開発を遅らせる不要な部分を排除し、ソフトウェアの拡張コストを削減できます。

コードの臭いとは、通常、システムのより深い問題に対応する表面的な兆候のことです。この用語は、私がリファクタリングの本を執筆する際に、ケント・ベックが考案したものです。

標準的な規模のチーム内では、あらゆる種類のテクノロジーに対する選択肢を3つに制限します。それは、現状で妥当なデフォルト、トライアルとして実験しているもの、そして嫌いで廃止したいものの3つです。

Design Stamina Hypothesisにおいて、設計ペイオフラインとは、市場投入までの時間と引き換えに設計品質を犠牲にしても良い機能量の限界のことです。

ソフトウェアをきちんと設計する価値はあるのか？

(辞書への追加です。)

テスト不可能（形容詞）：テストできないソフトウェア。

技術的負債は非常に有用な概念ですが、どのように測定するかという疑問が生じます。残念なことに、技術的負債は金融上の負債とは異なり、どれほど負債を抱えているかを判断するのは容易ではありません（最近、金融上の負債の測定にも苦労しているようですが）。

ソフトウェアシステムは、粗悪な部分（内部品質の欠陥）の蓄積を起こしがちです。これは、システムの修正や拡張を理想よりも困難にするものです。技術的負債は、ウォード・カニングハムによって考案された比喩で、この粗悪な部分への対処方法を、金融上の負債のように考えるフレームワークを提供します。新機能を追加する際に必要な追加の労力は、負債の支払利子です。

過去数ヶ月にわたって技術的負債に関するいくつかの投稿があり、どのような設計上の欠陥を技術的負債として分類すべきか、またはすべきでないかという疑問が提起されました。